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ABSTRACT 

The  use  of  standard  procedures  in  development  and  documentation 
of  automated  systems  has  become  a  necessity,,  Many  activities  in 
Government  and  indus  i  i  /  are  expending  a  large  effort  in  manpower 
and  costs  in  duplicating  procedures  and  documentation  that  may  have 
been  prepared  many  times  before.  An  effort  has  been  made  in  this 
paper  to  describe  an  approach  to  a  standardized  system  of  develop- 
ment and  record  keeping  that  would  preclude  duplicating  effort 
previously  expended  in  the  same  area. 

The  paper  follows  the  development  of  an  automated  system  from 
its  inception  to  completion  recommending  methods  for  recording 
procedures  used  in  automating  a  functional  process. 
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CHAPTER  I 
A.   INTRODUCTION 

In  developing  an  automated  system,  whether  it  be  military  or 
commercial,  the  proper  planning,  analysis  and  design  is  dependent 
upon  adequate  data,  systematically  developed  and  properly  docu- 
mented. The  purpose  of  this  paper  is  to  present  the  logical  devel- 
opment of  an  automated  system  from  its  inception  to  completion. 
Emphasis  will  be  placed  on  proper  and  timely  documentation  require- 
ments • 

Thousands  of  automated  systems  have  been  and  are  being  de- 
signed by  government  and  industry.  Computers  are  becoming  contin- 
ually more  sophisticated  and  the  output  (reports,  display,  etc.) 
of  these  automated  systems  are  extremely  well  developed.  The  "State 
of  the  Art"  for  automated  systems  had  advanced  much  more  rapidly 
than  its  administrative  development  and  documentation.  In  other 
words,  we  have  ultramodern  systems  and  archaic  methods  of  admin- 
istrative control  and  record  keeping.  Part  of  the  reason  for  this 
is  the  lack  of  glamour  to  this  extremely  necessary  segment  of 
development.  It  may  never  be  glamorous,  but  it  must  be  performed, 
else  we  build  on  a  foundation  of  sand. 

Two  major  questions  arise  in  administrative  development  and 
documentation.  These  are,  who  should  control  this  development  and 
how  must  it  be  controlled. 

In  a  recent  Senate  Report  to  the  President  on  "...The  manage- 


ment  of  Automatic  Data  Processing  in  the  Federal  Government"  Jl J 

Many  of  the  problems  in  the  field  of  Data  Processing  Management 

were  discussed*  It  outlined  the  problem  of  who  should  control 

administrative  development  as  follows  § 

The  assignment  of  appropriate  roles  to  the  different 
echelons  of  management  in  the  Federal  Government  is  of  great 
importance.  Some  computer  applications,  particularly  those 
involved  in  administrative  functions;  have  a  great  deal  in 
common  and  conceivably  could  be  subject  to  greater  central- 
ization. On  the  other  hand,  the  more  significant  computer 
applications  are  integral  parts  oj  agency  programs;  accord- 
ingly, each  is  a  unique  application  and  its  management  is  a 
responsibility  of  those  officials  charged  with  mission 
accomplishment.  The  problem  then  becomes  one  of  improving 
the  effectiveness  and  the  economy  of  computer  utilization, 
both  within  an  executive  agency  and  in  the  government  as  a 
whole,  without  derogating  the  proper  authorities  and 
responsibilities  of  managers  in  the  line. 

This  problem  has  not  gone  unnoticed  in  that  the  report  provides 

jgfti 
for  some  macro -type  solutions  by  reconmending  thats 

1.  The  Bureau  of  the  Budget  will  develop  a  broadly  based 
program  of  continuous  evaluation  of  computer  systems,  to 
provide  an  assessment  of  accomplishments  and  to  serve  as  a 
recurring  source  of*  information  for  the  development  or 
revision  of  policies  and  guidelines.  The  responsibility  for 
conducting  evaluations  and  preparing  appropriate  reports  will 
rest  with  the  agency  heads,  in  accordance  with  their  normal 
management  responsibilities. 

2.  The  Bureau  of  the  Budget  will  develop  criteria  to  assist 
in  evaluating  both  systems  design  and  various  aspects  of 
system  performance. 

3.  Agencies  should  develop  master  data-processing  plans  at 
appropriate  levels,  to  serve  as  guides  in  the  orderly  devel- 
opment of  systems  and  to  assure  the  most  effective  use  of 
staff  resources  available  for  that  development. 

4.  The  Department  of  Commerce,  through  the  National  Bureau 
of  Standards,  should  expand  the  advisory  service  currently 
being  provided  to  agencies  in  the  analysis  and  design  of 
computer-based  systems.  Its  resources  allocated  for  this 
purpose  should  be  increased  to  the  extent  required  to  meet 
such  needs  as  fully  as  possible. 

The  report  also  emphasizes  the  necessity  of  managers  to  concern 


themselves  with  all  aspects  of  Data  Processing  from  the  determina- 
tion of  objectives  to  the  utilization  of  the  end  product. 

One  of  the  major  concerns  of  the  data  processing  manager  is 
that  of  documentation  criteria  and  documentation  standards. 
Recognition  of  the  importance  of  these  problems  is  emphasized  in 
the  Senate  report  in  that  two  of  the  twelve  major  actions  alluded 
to  them  -  i.e.  -  action  number  7  and  12  noted  below. 

#7.  Strengthen  Government  support  of  programs  initiated 
by  the  American  Standards  Association  to  achieve  needed 
compatibility  among  automatic  data  processing  equipment  and 
systems. 

#12.  Propose  the  enactment  of  legislation  by  Congress 
which  would:  ... 

(b)  strengthen  the  authorities  for  the  development, 
testing  and  implementation  of  standards;  the  Performance  of 
Research  in  computer  sciences  and  the  provision  of  advisory 
services  by  the  National  Bureau  of  Standards. 

Standardization  is  described  by  Dr.  Otto  Frank  as 

The  regularization  or  establishment  of  what  is  approved  as 
good  or  valuable.  It  aims  to  reduce  the  uncoordination, 
confusion  and  waste  that  ensue  from  a  needless  variety  of 
products  or  methods,  and  to  discourage  the  persistence  of 
practices  which  experience  has  shown  to  be  less  good  than 
the  best. 

In  other  words,  use  procedures  that  are  generally  accepted 

in  the  field  of  management  and  data  processing.  How  does  one  know 

what  is  generally  accepted  as  being  "Good  or  Valuable?"  The 

answer  to  the  question  has  not  been  fully  considered,  however: 

The  Federal  Government  is  now  vitally  interested  in  the  answers. 

A  step  toward  an  acceptable  answer  is  being  made  as  a  result  of 

the  above  mentioned  Senate  Report  which  states  in  part: 

Frank,  0.,  Modern  Documentation  and  Information  Practices, 
International  Federation  for  Documentation,  1964,  1. 
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Figure  1 


A  related  problem  (to  compatability  of  computer  systems) 
is  the  lack  of  standardization  of  data  elements  in  common 
use  and  the  codes  used  ^J»  represent  those  elements .   ....Today, 
the  close  interrelationship  among  systems  of  different  agencies 
or  the  centralized  summarization  of  data  common  to  all  agencies, 
■jj^lT  demands  that  data  elements  or  codes  representing  an  element 
of  data  be  standard  for  the  Government."  [jp^ 

In  one  area  of  standardization,  that  is  the  area  of  flow  charting 
automated  systems,  the  Department  of  Defense  has  developed  standard 
flow  charting  symbols.  Figure  1  displays  these  standard  symbols. 

An  example  of  where  the  problem  of  lack  of  standardization 
exists  is  the  area  of  command  and  control  in  the  Department  of 
Defense.  The  Army,  Navy,  and  Air  Force  each  have  their  own  method 
of  preparing  documents.  There  is  some  effort  to  develop  standard 
programming  techniques  and  language  through  joint  standardization 
committees  within  the  Department  of  Defense.  However,  there  is  a 
great  deal  still  to  be  accomplished  in  the  area  of  documentation 
standards.  The  Army  developes  the  majority  of  their  automated 
programs  "in  house"  without  the  use  of  contractor  assistance.  The 
Navy  uses  a  combination  of  "in  house"  effort  and  contractor  assist- 
ance. The  Air  Force  uses  mainly  contractor  effort  in  development. 

A  more  detailed  look  at  both  problems  of  "who"  and  "how"  has 

2 
been  well  developed  by  John  T.  0arrity  in  an  article  describing 

a  study  conducted  by  McKinsey  &  Company  on  the  experiences  of 

twenty-seven  major  companies  in  13  different  industries. 

These  companies  have  invested  on  the  aggregate  over  $100 

million  a  year  in  automation  and  all  have  had  at  least  four  years 

2 

Garrity,  J.  T.,  Top  Management  and  Computer  Profits. 

Harvard  Business  Review,  July-Aug  1963,  6. 


computer  experience. 

The  survey  sought  to  discover  each  company* s  opinion  on  the 
success  of  the  venture  based  on  the  criteria  of: 

1.  Dollar  Return  from  computer  system  investment. 

2s.  Long  term  indirect  benefits. 

3.  Range  and  scope  of  applications  currently  using  the  computer. 

The  results  were  quite  decisive.  The  companies  fell  into  two 
distinct  groups;  a  group  of  nine  had  very  successful  results  and  a 
group  of  eighteen  whose  results  were  marginal  at  best.  There  were 
none  that  were  moderately  successful. 

In  order  to  isolate  the  basic  factors  that  determine  the 
successful  operation,  the  survey  used  six  areas  of  investigation 
for  a  comparative  analysis.  These  areas  weres 

1.  The  quality  of  executive  leadership  provided  for  the 
computer  systems  effort. 

2.  The  soundness  of  planning  and  control  tools  used  in 
managing  the  effort. 

3.  The  degree  of  operating  management  involvement. 

4.  The  caliber  of  the  computer  systems  technical  staff. 

5.  The  role  of  the  corporate  computer  systems  staff. 

6.  The  equipment  strategy. 

In  each  area  the  question  and  responses  were  divided  into  two 
categories;  those  responses  which  reflected  major  differences 
between  the  successful  and  unsuccessful  companies  and  those  responses 
which  reflected  basic  similiarities. 


Mr.  Garrity  concludes  that  there  were  eleven  major  differences 
between  the  successful  and  unsuccessful  companies. 

In  the  successful  companies  ^he  executive  management  devoted 
a  reasonable  proportion  of  Jshcir  time  to  the  computer  system, 
subject  to  its  cost  and  potential  in  relation  to  other  executive 
responsibilities.  This  did  not  mean  that  they  were  involved  in 
the  technical  aspects  of  development,  but  in  the  management 
problems  involved  in  integrating  the  computer  system  with  the 
management  process.  This  means  they  spend  time  reviewing  plans 
and  progress  and  insure  that  proper  results  are  achieved. 

Before  any  application  is  initiated  in  the  successful  company 
a  careful  feasibility  study  is  conducted  to  insure  that  the 
application  is  cost  effective  and  practical.  Once  a  project  is 
initiated,  project  development  and  progress  is  followed  closely  by 
the  corporate  management  including  the  chief  executive.  These 
leading  company  executives  were  continually  looking  for  methods  to 
strengthen  l&heir  management  control  over  the  computer  systems 
effort. 

In  the  area  of  operating  management  involvement  in  the  computer 
systems  effort  there  appeared  the  greatest  divergence  between  the 
two  classes  of  company. 

The  lead  company's  operating  management  took  a  very  active 
role  in  the  selection,  planning  and  manning  of  the  projects  under- 
taken. This  appears  to  be  due  to  several  factors,  including  top 
management's  attitude  of  fostering  effective  staff-line  relation- 


ship  and  an  atmosphere  favorable  to  an  innovating,  inquiring 
approach^.  In  addition,  top  management  has  clearly  defined  the 
operating  executives  role  in  the  computer  system  effort. 

The  role  of  the  technical  staff  is  very  clearly  defined  by 
the  executive  leadership  of  the  lead  companies.  The  need  for  a 
competent  and  well  staffed  technical  capability  was  recognized. 
These  companies  not  only  provided  this  but  further  supplemented 
their  systems  skills  by  including  management-sciences  personnel 
on  the  staff. 

Each  successful  company  in  general,  provided  a  computer  exec- 
utive who  could  function  effectively  with  limited  technical  knowl- 
edge at  the  first  or  second  level  below  the  chief  executive  and  a 
computer  systems  manager  who  had  extensive  technical  skill  at  the 
next  level  below  the  computer  executive.  This  appeared  to  provide 
sufficient  technical  effectiveness  with  proper  management  control. 

In  general,  the  lead  companies,  placed  the  computer  system 
organization  in  the  corporation  at  the  division  level  with  as 
little  disturbance  to  the  company  organization  as  possible.  This, 
however,  did  not  seem  to  b£,  a  major  factor  in  the  success  of  the 
company's  effort. 

It  is  also  noteworthy  that  all  the  companies,  successful  and 
unsuccessful  tended  to  have  the  same  equipment  strategy. 

The  overall  basic  factors  derived  from  the  survey  appear  to 
show  that  top  management  must  correctly  assess  the  computer's 
potential  and  provide  the  continuing  management  guidance  that  i| 


requires. 

We  must  therefore  conclude  that  the  answer  to  "Who"  part  of 
the  question  of  control  is  that  all  management  from  the  chief 
executive  to  the  operating  and  technical  staff  must  take  a  active 
role  in  the  operation  with  top  management  taking  a  lead  role.  The 
answer  to  the  "How"  part  is  much  the  same,  top  management  taking 
an  active  part  in  establishing  policies  and  guidelines  and  the 
close  cooperation  of  the  operating  and  technical  staffs  in  carrying 
them  out. 

B.  OBJECTIVE 

It  is  the  intention  of  this  paper  to  describe  the  functional 
steps  in  the  development  of  an  automated  system  and  delineate  the 
documentation  required. 

The  logical  sequence  of  events  in  this  development  are: 
Planning,  Analysis,  Development,  Evaluation  and  Operation  of  the 
System.  Planning  will  include  the  problem  definition  and  study  to 
determine  the  feasibility  of  the  solution.  Analysis  is  the  detailed 
study  which  determines  the  method  of  solution  of  the  problem. 
Development  would  be  the  program  preparation.  Evaluation  can  be 
considered  the  test  to  determine  if  the  solution  to  the  problem  is 
correct  and  adequate.  Operation  is  using  the  system  as  designed. 
Each  will  be  considered  and  the  documentation  requirements  for 
each  phase  will  be  outlined. 

In  the  development  of  an  automated  system,  the  first  consid- 
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eration  must  be  given  to  the  type  of  unit  that  will  perform  the 
development.  This  unit  may  be  internal  to  the  organization 
requesting  the  development  such  as  the  computer  system  division 
of  a  activity  or  may  be  an  external  activity  contracted  to  perform 
the  automation  such  as  commercial  commercial  consulting  firms.  In 
either  case  the  unit  performing  the  development  must  be  properly 
and  adequately  staffed.  This  means  the  proper  mix  of  systems 
analysts,  operations  analysts,  system  programmers,  and  technical 
writers  with  adequate  experience  in  the  field  of  program  develop- 
ment. Obtaining  such  a  qualified  group  may  be  a  major  problem 
since  these  type  of  skills  are  in  great  demand.  One  consulting 
firm  known  personally  to  this  author  has  a  policy  that  it  will 
hire  only  individuals  who  can  substantiate  five  years  experience 
in  their  respective  field.  It  is  assumed  for  the  purpose  of  this 
paper  that  this  important  function  is  available  and  competent. 
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CHAPTER  II 

PLANNING 

The  planning  phase  of  the  development  can  be  considered  the 
problem, definition  and  problem  analysis  phase.  It  consists  of  the 
system  requirement  development  (determination  of  the  problem),  the 
design  study  (problem  definition  and  analysis)  and  the  design 
review  and  approval.  The  system  requirement  is  generally  deter- 
mined by  the  activity  or  organization  desiring  automation  of  a 
function  (hereafter  called  the  user  or  user  activity) •  The  unit 
or  activity  performing  the  analysis  and  programming  will  be  known 
as  the  developer  or  developing  activity, 

A.  THE  SYSTEM  REQUIREMENT 

The  initiation  of  an  automated  system  will  be  by  users 
recognizing  that  their  present  method  of  operation  is  inadequate, 
inefficient  or  ineffective.  The  question  that  usually  starts  a 
new  approach  iss  nIsnvt  there  a  better  way?w  The  answer  is 
usually  -  Yes. 

The  general  context  of  the  example  given  in  this  paper  will 
be  that  of  a  Naval  activity,  however,  the  same  basic  problems  and 
solutions  will  arise  in  almost  any  field. 

The  system  requirement  document  must  provide  a  clear  and 
concise  explanation  of  the  problem.  It  must  define  the  objectives 
of  the  system  and  describe  in  detail  the  present  method  of  oper- 

11 


ation.  It  must  describe  the  present  deficiencies,  the  data  avail- 
able and  the  desired  goals,  including  when  the  new  capability  is 
required. 

A  description  of  the  requirement  is  a  vital  part  of  the 
system  analysis  and  care  must  be  taken  that  adequate  information 
is  provided  to  insure  that  the  correct  problem  is  analyzed  and 
solved.  The  user  prepares  this  document  without  the  assistance 
of  the  developer.  This  is  done  to  insure  that  only  the  users 
concept  of  the  problem  establishes  the  requirement  since  he  is 
generally  oriented  functionally  and  is  able  to  define  the  problem 
that  he  wishes  solved.  If  the  assistance  of  the  developer  is  used 
there  is  the  possibility  of  distortion  of  the  problem  to  fit  the 
developer1 s  preconceived  concept  of  operation.  Thus,  the  require- 
ment document  must  contain  the  requestor's  concept  of  operation 
providing  a  non-technical  description  of  the  capability  required 
and  specifying  what  tasks  are  desired.  These  tasks  refer  to  the 
various  phases  of  development  of  the  automated  system.  This  may 
range  from  a  feasibility  study  to  the  complete  analysis  and 
implementation  of  the  system. 

This  requirement  document  must  contain  an  identification 
number  or  code  that  will  indicate  the  activity  requesting  the 
project.  This  may  be  an  internal  or  external  activity.  As  an 
example,  there  may  be  requests  from  the  control  division  or  the 
Technical  division  of  the  activity  performing  the  function  of 
automating  or  from  an  external  activity.  Each  may  be  assigned 
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a  code  for  identification  and  cross  reference.  A  code  that 
indicates  the  classification  of  the  function,  such  as,  operations, 
Intelligence,  communications  or  logistics  should  also  be  assigned. 
Any  system  of  identification  and  ready  reference  would  be  accept- 
able if  »it  insures  cleary  concise  classification.  The  method  de- 
scribed above  is  currently  in  use  in  the  Naval  Command  and  Control 
System.  It  provides  a  two  digit  code  for  the  requesting  activity, 
a  single  letter  code  for  the  functional  area  and  a  serial  number 
indicating  time  of  receipt.  An  additional  code  could  be  used  for 
priority  classification. 

A  noun  title  would  usually  be  assigned  for  ease  of  nonauto- 
mated  reference. 

In  addition,  the  priority  and  date  capability  is  required 
must  be  included.  These  factors  will  assist  in  determining  the 
feasibility,  timeliness  and  appropriateness  of  the  project. 

B.  DESIGN  STUDY 

Upon  receipt  of  the  system  requirement  by  the  systems  analysis 
group,  a  design  or  feasibility  study  is  conducted.  This  study 
should  be  conducted  in  close  liasion  with  the  user. 

The  study  group  will  analyze  the  requirement  in  detail, 
defining  the  present  system,  the  data  inputs,  the  data  formats, 
detail  processing  being  conducted,  output  data  and  form  of  pres- 
entation. 

A  definition  and  explanation  of  the  present  activity's 
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responsibilities  and  the  desired  capabilities  to  be  provided  by 
the  new  system  must  be  made. 

An  analysis  will  then  be  made  of  the  organizational  relation- 
ship within  the  activity  by  the  use  of  information  flow  analysis 
including  all  interactions  within  the  activity  and  witf|  all 
concerned  parties  outside  the  activity.  Information  flow  analysis 
concerns  itself  with  data  and  document  transmission  without 
considering  organizational  structure.  It  is  a  derivation"  of  pert 
analysis  on  documents  and  data. 

Problem  areas  such  as  duplication,  dual  responsibility  and 
inconsistencies  will  be  described. 

A  comparison  will  be  made  of  the  organization  functional  pro- 
cedures with  the  information  flow  analysis  to  clarify  differences 
and  provide  background  for  recommended  revisions. 

This  may  also  be  called  a  Systems  analysis.  It  involves 
collecting,  organizing,  analysing  and  evaluating  the  pertinant 
facts  about  the  present  system  and  its  environment.  This  is 
accomplished  by  determining  the  input  and  output  requirements  of 
the  present  system,  the  sources  of  data,  the  method  of  processing, 
(eg.  ADP,  EAM  Manual,  etc.)  the  frequency  and  volume  of  the  data 
transactions. 

Now  for  the  development  of  a  new  system,  the  systems  analyst 
must  be  fully  cognizant  and  responsive  to  acceptable  standards  of 
procedure.  The  analysis  is  conducted  by  the  developer  with  the 
cooperation  of  the  user  staff. 
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CARD  COD"  (1) 


/ 


FORM  NO.    (2-3) 

FORM  TITLE  (9-24) 

L0C       FZZO 

alpha              nu/nerlo 

K^,Q,S{T\     .APiOi^i 

iStKltlLlL 

STATION  (25-23) 

6 

MANPOWER 

activity  nam* 

1  \3\OxO 

code 

EVENT  or  SEQUENCE  (30-49) 

oode 

fc.e.V./ir.itf,   ,#5,c,a,Uie-,«,T,y.,Ai/Vi^ii^i« 

IDENTITY  (29) 

Output 

0 

1 

A 

File/Output 

FO 

2 

B 

Report 

R 

3 

C 

Input 

I 

4 

D 

Input/Output 

10 

5 

E 

Input  File 

IF 

S 

F 

In/Fllo/Out 

IX 

<3) 

C 

File 

F 

fi 

H 

PHYSICAL  FOFM  (50) 
all   oodcs    except  6 

FILES   -   code 

S 

Document  (manual) 

DM 

1 

Drawer 

1 

Docunont  ( typod) 

DT 

<2> 

Folder 

2 

Document  (prooess) 

DP 

3 

Chart 

3 

Punoh  Cord 

PC 

4 

Statu* 

4 

Telephone   Call 

TC 

5 

Sheet 

5 

Teletype  Message 

TM 

6 

Ledger 

6 

Radio  Message 

RM 

7 

Kardex  Cards 

7 

Verbal  Message 

VK 

e 

3x5   Cards 

e 

Paper  Tape 

PT 

9 

Tag 

9 

Ma^ietlc  Tape 

MT 

0 

FREQUENCY  (64) 

Hourly 

H 

Dally 

D 

Weekly 

W 

Semi -monthly 

s 

Bl -weekly 

B 

Monthly 

K 

Quarterly 

(D 

Seal -annually 

E 

Annually 

A 

As  Required 

R 

SPECIAL   TIME  REO'MTS 
(65-66) 


None 

Immediate 

Hour 

Day 

Month 


(blank) 


IM 


VOLUME  (67-70) 


DISPOSITION  (71-75) 

STATION  NO.   (71-74) 

persTXoy  |9999  • 

Hand  carry 

1 

Telephone 

2 

Verbal 

3 

Radio 

4 

Regular  Mall 

S 

Airmail 

6 

Teletype 

7 

DISPOSITION  (76-90) 

STATION   NO.   (76-79) 

1 

Hand  carry 

1 

Telephone 

2 

Verbal 

3 

Radio 

4 

Regular  Mall 

5 

Airmail 

6 

Teletype 

7 

SOURCE  (51-54) 

PLANNING 

aotlvity  name 

8\l  \0\O 

code 

PROCESSING  ACTION  (55-56) 

Soetion  At   actions  affeoting  forms 

Seotion  Bi    aotlons   resulting  in  other  aotlons 

10 

Operate 

20 

sign 

11 

update 

30 

Transport 

12 

extraot 

40 

Delay 

13 

pull 

SO 

Store 

Seotlon 
A 

14 

16 

17 
18 

post 
prepare 
compare  with 
referanoe 
complete 

60 

Inspect 

FORM  NO.    (57-63) 

19 

tag 

M 

2>C    i  FZIO 

70 

Notify 

76 

Inspeot 

71 

Brief 

77 

Correot 

Seotlon 

B 

72 
73 
74 

Request 
Dl  spa  ton 
Scramble 

STATION  NO.    (57-63] 

75 

Return 

Figure    2        •  Message  specification  sheet. 
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The  most  generally  accepted  method  of  conducting  an  analysis 
involves  the  following  series  of  logical  steps s 

First,  the  facts  or  data  must  be  assimilated.  This  is  done 
by  interviewing  personnel  and  observing  activities  performed  in 
the  system. 

Second,  obtain  sample  copies  of  all  data  inpuft'r'and  outputs 
-  i.e.  documents,  files,  including  statistics  and  processing  time, 
frequency  and  volume  encountered  during  the  operation. 

Third,  learn  the  processingjjj^perations  and  determine  how  and 
why  each  item  in  the  system  is  processed. 

Fourth,  organize  the  data  obtained  into  a  systematic  and 
logical  flow,  noting  redundancies,  overlaps,  duplication,  omissions, 
and  the  development  of  new  concepts  proposed  or  informally  initiated 
by  the  user  personnel. 

Fifth,  review  the  data  obtained  with  the  personnel  involved 
to  determine  if  data  is  correct  and  flow  developed  is  a  true 
representation  of  this  data.  The  key  to  successful  completion  of 
these  five  steps  is  complete  and  clear  documentation  as  illustrated 
below: 

Document  Specification  and  Disposition  Form.  This  is  a  standardized 
form  for  presenting  detailed  specification  and  disposition  of  any 
communication.  It  provides  a  sequence  number  for  integration  into 
the  flow  analysis.  The  form  is  of  a  general  nature  therefore  may 
be  used  by  virtually  all  analysts  for  all  types  of  communications. 
It  provides  a  card  code,  form  number,  and  title  for  identification 
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and  cross  reference.  The  analyst  prepares  this  form  as  he  is 
interviewing  personnel  responsible  for  preparation  and  disposition 
of  the  document  under  consideration.  He  identifies  the  activity 
currently  processing  the  document,  the  processing  action,  the 
physical  form,  the  frequency  of  processing  and  disposition.  With 
this  form  he  is  able  to  follow  the  sequence  of  actions  on  each 

i. 

document  within  a  specific  activity  or  follow  any  document  as  it 
is  processed  by  each  activity. 

Figure  2  is  an  example  of  this  form.  The  document  is  a 
"request  for  additional  skill'*  from  the  planning  department  to  the 
manpower  department.  As  indicated  the  manpower  section  must  prepare 
a  typed  answer.  This  action  is  done  on  a  quarterly  basis.  There 
is  no  special  time  requirements  on  the  action. 

This  form,  along  with  a  completed  copy  of  the  document  provide 
the  input  data  for  the  system  analysis.  The  forms  and  copies  of 
documents  are  edited,  summarized,  analyzed  and  flow  charted  to 
provide  a  comprehensive,  quantified  understanding  of  the  data  flow 
throughout  the  organizational  area  being  considered. 

The  conclusions  from  this  analysis  will  provide  documentation 
on  location  characteristics  and  relationship,  file  analysis,  network 
and  location  load  analysis,  document  activity  analysis,  and  flow 
analysis. 

Location  Characteristics  and  Relationships.  This  documentation  will 
include  description  of  files  and  the  type,  frequency,  volume  and 
special  requirements  of  the  data  processes  at  the  location.  It 
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indicates  the  function  of  the  location  as  to  origination,  control, 
storage,  or  relay  point  in  the  system.  The  relationship  of  various 
locations  in  the  system  provide  useful  information  in  deciding 
potential  for  integration  or  centralization.  The  description  of 
the  files  at  each  location  may  indicate  the  need  for  change  in 
storage  media  or  reduction  of  redundant  information. 
Network  Load  Analysis.  The  data  from  the  document  specification 
and  disposition  forms  are  sorted  by  station  identity,  form  number 
and  card  code  to  develop  reports  for  each  activity  by  identity, 
code,  frequency  of  processing  and  special  time  requirements.  The 
network  data  load  detail  report  shown  in  figure  3  list  all  docu- 
ments, forms  and  reports  processed  by  an  activity  (or  unit)  grouped 
by  identity  code,  frequency  of  processing  and  special  requirements. 
The  volume  of  documents  is  listed  by  frequency  of  processing  and 
converted  to  a  monthly  basis  to  facilitate  comparison  among  activ- 
ities. From  an  analysis  of  the  volume  associated  with  each  identity 
code,  the  analyst  can  determine  the  primary  function  of  the  activ- 
ity under  consideration.  Summary  reports  may  also  be  prepared 
showing  the  total  data  flow  network  and  the  relationship  of  each 
activity  to  the  overall  network  workload. 

This  form  indicates  that  Station  No.  2  processes  eleven  types 
of  documents,  each  on  a  monthly  basis  and  a  total  volume  of  forty 
per  month. 

Document  Activity  Analysis.  The  analyst  may  use  the  document 
activity  report  shown  in  figure  4  to  follow  the  document  flow 
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between  different  data  processing  areas,  functional  areas  and 
activities.  It  identifies  documents  processed  at  a  particular 
activity  and  separate  listing  can  be  prepared  for  documents  created 
and  used  by  the  same  unit.  The  degree  of  potential  integration 
within  and  between  functional  activities  can  be  established  from 
this  report.  Independent  activities  will  be  highlighted  because 
they  have  little  or  no  transfer  of  documents  to  or  from  other 
activities.  Closely  interrelated  data-processing  activities  in 
several  units  indicate  a  strong  case  for  centralized  processing, 
and  vice  versa. 

The  document  activity  report  illustrated  indicates  that  form 
no.  L0CC050,  a  requisition  has  interactions  within  the  Data  Services 
station  (2200)  and  also  with  stations  no.  8400  &  9300. 
Flow  Listing  Analysis.  This  analysis  uses  the  event-oriented 
approach  and  emphasizes  the  fact  that  an  event  creates  a  document 
or  action  at  a  particular  activity  and  focuses  the  analysis  on  the 
chain  of  related  events  as  illustrated  in  the  event-type  flow  list, 
figure  5.  It  shows  a  particular  event  and  its  sequence  in  the 
related  chain  of  events  by  activity  and  document  identified  with  it. 
The  processing  actions  taken  as  a  result  of  receiving  a  document  at 
a  particular  activity  are  identified  on  the  flow  list  as  affecting 
the  document  alone  or  as  also  initiating  some  other  operations.  It 
will  also  identify  incomplete  event  chains. 

The  Flow  Analysis  listing  provides  a  chronological  list  of 
events.  As  an  example  the  Data  Services  section  conduct  events 
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numbers  4-0  to  4-341000  using  document  numbers  KJLT080,  FIL60, 
FILT180  and  L0CE110  on  which  they  prepare  document  FIL60,  COMPUTE 
DOCUMENT  FIL61,  prepare  document  FIL180  and  compare  this  with 
document  FIL150.  The  final  disposition  of  this  series  of  events 
is  to  the  industrial  Engineering  Division. 

Comments  and  recommendations  are  made  from  these  analyses 
that  will  advise  on  adequacy  of  the  present  capability  and  recom- 
mend possible  improvements  to  the  present  system.  These  improve- 
ments will  be  of  two  types?  (1)  Improvements  that  would  not  require 
the  use  of  an  automated  system  and  (2)  Improvements  that  would 
require  the  use  of  an  automated  system. 

The  design  study  will  include  complete  organization  and  infor- 
mation flow  charts  of  both  the  present  system  and  the  proposed 
system  if  required.  See  Appendix  A  for  recommended  format  of  the 
report . 

C.  DESIGN  REVIEW  AND  APPROVAL 

The  design  study  report  will  be  presented  to  the  user  top 
management  for  review  and  approval.  The  systems  analysis  group 
together  with  the  user  personnel  assigned  to  assist  in  the  design 
study  should  be  available  to  clarify  any  phase  of  the  report  not 
understood.  This  approval  will  signify  that  the  user  and  the 
analysts  understand  the  requirement  and  agree  with  the  proposed 
developmental  approach.  It  should  be  stressed  here  that  this 
approval  does  not  bind  or  fix  the  design  irrevocably.  It  is 
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obvious  that  if  the  system  is  complex  and  dynamic  there  will  be 
changes  required,,  These  design  changes  may  be  major  or  minor  since 
the  design  study  will  not  generally  do  as  detailed  an  analysis  as 

is  required  by  the  complete  operational  and  functional  design. 
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CHAPTER  III 


ANALYSIS 


The  analysis  phase  of  development  is  the  connecting  link 
between  the  design  and  programming  of  an  automated  system.  It  is 
much  more  detailed  in  that  it  provides  analysis  of  the  problem 
from  a  functional  point  of  view,  that  is,  it  describes  the  system 
being  developed  by  the  functions  or  tasks  that  are  being  automated 
and  describes  how  these  functions  and  tasks  will  be  automated. 

DETAILED  SYSTEMS  ANALYSIS 


With  the  approval  of  the  design  study,  the  more  extensive 
systems  analysis  may  be  initiated.  This  is  accomplished  in  two 
phases,  i.e.;  the  functional  analysis  and  the  operational  analysis. 

The  first  step  in  conducting  these  analyses  is  the  preparation 
of  a  "Plan  of  Attack"  or  development  plan.  This  development  plan 
will  give  estimates  of  time  and  effort  required  to  develop  the 
system.  These  estimates  will  be  the  best  judgement  of  the  analysts 
and  programmers  of  the  scope  and  range  of  the  system  and  will  be 
prepared  by  phases.  They  will  contain  man-day  (month,  year)  effort 
required  to  accomplish  the  phase.  Time  tables  and  "milestone" 
dates  by  which  the  progress  of  the  development  may  be  measured  will 
be  included.  It  should  be  emphasized  here,  that  this  is  only  an 
estimate  of  the  effort  required  based  on  the  best  information 
available  to  the  analysts.  The  phases  will  be  divided  into  the 
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analysis  phase ,  the  coding  (Programming)  phase,  the  testing  phase, 
the  data  collection/conversion  phases  training  and  turnover  phase. 
Figure  6  provides  a  sample  of  time  phasing  that  illustrates  the 
sequence  of  events  and  actions. 

The  analysis  phase  progress  can  only  be  measured  by  the 
expected  number  of  manhours  to  complete  the  phase^,  the  coding  phase 
progress  can  be  measured  by  the  nuber  of  coding  instructions 
completed  in  a  certain  time  period.  The  present  "State  of  the  Art" 
provides  very  little  data  on  what  is  an  average  number  of  coding 
instructions  or  steps  that  should  be  completed  in  a  specified 
period.  Some  programming  organisations  use  ten  "debugged"  pro- 
gramming steps  per  day  as  a  standard.  This  is  a  very  uncertain 
measurement  since  a  great  deal  depends  on  the  complexity  of  the 
program  and  the  interactions  necessary  with  other  systems.  In  the 
|est  and  checkout  phase  the  measurement  of  progress  (and  again  an 
unsure  one)  is  the  number  of  hours  of  computer  time  required  to 
make  the  system  operable.  Some  of  the  possible  criteria  for 
measuring  efficiency  and  progress  in  the  coding  and  system  check- 
out phases  may  bes 

1.  Minimum  programming  effort  i»e$  the  simplest  method  for 
coding  to  provide  minimal  coding  and  debugging  time. 

2.  Program  execution  time  minimum  i.e°  minimal  computer 
running  time. 

3.  Insure  that  the  program  occupy  as  little  computer  memory 
as  possible. 


4.  Provide  a  program  that  is  flexible  c!  i.ej  insure  the 
program  is  relatively  easy  to  modify  or  change. 

Each  of  these  criteria  or  constants  will  require  the  analyst 
to  consider  alternative  methods  of  system  development.  Figure  7 
contains  a  recommended  format  for   development  plan, 

1,  Functional  Analysis 

A  comprehensive  scientific  investigation  to  define  the  problems 
and  the  most  feasible  method  of  solution  from  a  functional  stand 
point  is  now  conducted,,  taking  into  consideration  both  effectiveness 
and  cost.  It  will  include  a  more  detailed  review  and  analysis  of 
the  user  requirements  and  of  the  information  flow  than  was  completed 
for  the  design  study.  The  design  study  will  be  the  starting  point 
for  this  analysis. 

With  this  design  study  the  analyst  must  describe  the  scope  and 
function  of  the  system.  Using  the  information  flow  analysis 
completed  in  the  design  study 9  a  comparison  of  the  document  commu- 
nications process  is  made  with  the  formal  organizational  communica- 
tions process  that  will  enable  him  to  discover  duplication,  redun- 
dancies and  inadequacies  that  were  not  readily  apparent  during  the 
design  study.  This  will  allow  him  to  design  the  new  system  allevi- 
ating many  of  these  problems .  This  may  appear  to  be  redundant 
effort  in  view  of  the  design  study  effort,  however,  it  is  advisable, 
at  this  later  point  in  the  development,  to  review  the  flow  analysis 
to  determine  if  any  changes  in  concept  corrects  deficiencies  dis- 
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covered.  There  are  several  methods  available  to  perform  those 
tasks.  One  method  may  be  the  use  of  "automated  analysis.'1   The 
Rand  Corporation  had  developed  a  system  called  ro Auto sate"  (Auto- 
matic Data  System  Analysis  Technique).  Autosate  is  an  electronic 
processor  for  organizing  and  analysing  the  facts  collected  about 
the  flow  of  data  in  the  system.  It  provides  simplified  and 
standardized  input  collection  so  the  data  collection  may  be  accom- 
plished by  a  non  analyst.  It  performs  most  of  the  routine  tasks 
of  checking,  tracing,  reconciling^,  verfiying  and  flow  charting  of 
da^ta  so  that  the  analyst  may  conduct  the  more  rigorous  higher 
level  analysis  and  creative  design  work. 

The  International  Business  Machines  Corporation  has  also 

developed  a  systems  analysis  program  in  connection  with  their 

4 
Documentation  Aids  System.   This  particular  analysis  program  is 

limited  in  that  it  can  be  used  only  to  analyze  an  automated  system. 

It  is  designed  tos 

la  Improve  and  update  documentation  of  existing  programs. 

2,  Ease  maintenance  problems  by  providing  up  to  date  program 
documentation. 

3.  Eliminate  certain  clerical  and  routine  functions  associated 
with  documentation  and  conversion. 

3 
Gregory,  R.  H.  and  R.  L.  Van  Horn,  Automatic  Data  Processing 

Systems  -  Principles  and  Procedures,  1964s  190. 

4IBM  Reference  C20-1612,  Kingston,  Nei  York  (1964) 

- 
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4.  Improve  programming  efficiency  by  the  standardization  of 

documentation  techniques. 

5.  Encourage  the  user  to  re pro gram  in  a  higher-level  language 

5 
as  an  example,  Fortran,  Algol  and  Cobol. 

This  makes  it  ideal  for  redesign  or  updating  of  an  automated 
system  but  provides  little  assistance  in  development  of  a  previously 
nonautomated  one. 

Other  methods  of  analyses  are  those  of  Simulation ,  run  diagram- 
ming, structural  flow  charting,  or  use  of  decision  tables. 

Simulation  is  a  well  known  technique  which  flows  throv.gh. 
step  by  step,  the  events  that  are  expected  to  occur  in  a  proposed 
system  using  prior  experience,  logical  forecasting  and  probability 
theory  to  estimate  the  timing,  number  and  type  of  occurrences  that 
will  result  from  various  combinations  of  input  data.  This  is  a 
far  less  expensive  process  than  actual  operational  development. 

Run  diagramming  presents  a  general  overall  view  of  the  major 
functions  of  a  system,,  It  shows  fundamentally  in  short  English 
language  statements  how  the  various  files,  data  and  processes 
interact  in  the  system.  It  is  a  very  much  simplified  version  of 
the  programming  flow  charts  which  provide  much  higher  level  of 
detail.  Figure  8  gives  an  example  of  a  run  diagram  that  shows  the 
procedure  for  updating  an  inventory  file  and  the  method  for  reor- 
dering on  a  periodic  basis 0  Each  rectangular  box  represents  a 

5Ibid 
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Figure   10    Procedure  for  file  reading  and  balance  updating. 
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Figure    11       Decision  table  for  inventory  file  updating. 
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run,  i.c;  the  processing  of  one  set  of  inputs.  The  arrows  show 
whether  a  file  or  document  is  an  input  to  or  output  from  a  run  and 
the  numbers  indicate  the  volume,  In  Run  1,  the  data  in  the  inventory 
transaction  file  are  sorted  into  sequence  by  stock  number  and  trans- 
action type.  In  Run  2,  both  the  sorted  inventory  transaction  file 
and  the  Inventory  master  file  are  inputs  to  processing.  The  outputs 
from  processing  are  the  updated  master  file  of  a  use  in  the  next 
cycle,  lists  of  changes  applied,  a  reorder  list,  and  errors.  Error 
may  consist  of  transaction  records  without  corresponding  master 
file  records,  records  out  of  sequence  and  negative  balances. 

The  structural  flow  charts  mentioned  above  are  prepared  during 
the  overall  design  of  an  automated  system.  They  describe  the  time, 
quantities  and  type  of  inputs,  processing,  output  and  files.  They 
may  be  differentiated  from  programming  flow  charts  in  that  they 
give  a  general  description  of  the  process  in  more  detail  than  the 
Run  diagram  but  stop  short  of  presenting  program  instruction 
sequences.  A  sample  structural  flow  chart  is  shown  in  figure  9. 
It  illustrates  a  method  for  updating  an  inventory  master  file. 
Identification  names  (numbers)  are  given  to  the  major  blocks, 
documents  and  files,  This  name  or  number  should  be  used  on  all 
flow  charts  to  identify  the  same  items.  This  flow  chart  shows 
the  volume  of  activity,  i.ej  the  number  of  records  or  the  times 
each  path  is  used.  As  an  example  the  inventory  master  file  con- 
tains 1000  records  and  the  number  of  items  below  the  reorder  point 
is  sixty  (60)  as  indicated  on  the  "yes"  branch  from  the  test  for 
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inventory  balance.  These  figures  are  useful  for  calculating  work 
load  and  processing  times. 

Decision  tables  offer  a  more  versatile  display  of  diagramming 
various  sequences  of  action  than  does  the  structural  flow  chart. 
It  allows  the  illustration  of  several  alternate  sequences  of  action 
through  which  one  can  clearly  observe  the  obvious  path  through  the 
program.  In  flow  charting  it  is  difficult  to  obtain  such  a  path 
since  one  must  often  consider  all  the  prior  conditions  made  that 
may  influence  the  path  of  the  process.  The  use  of  decision  tables 
solves  this  problem,  in  that  all  prior  conditions  are  readily 
displayed.  Figures  10  and  11  provide  a  comparison  of  a  flow  chart 
and  a  decision  table  for  an  Inventory  file  updating  procedure. 

The  flow  chart  indicates  several  decision  diamonds  in  series 
to  describe  the  inventory  file  updating.  It  is  necessary  to  refer 
to  several  flow  charts  in  order  to  fallow  the  complete  inventory 
file  process.  This  procedure  becomes  very  complex.  As  an  example, 
if  the  transaction  type  is  greater  than  3  it  is  necessary  to  refer 
to  chart  A-1.2„2,  If  it  is  less  than  3  a  three  decision  diamond 
is  necessary.  The  numerals  indicate  the  number  of  expected 
actions.  With  the  decision  table  this  confusion  is  not  apparent. 

The  decision  table  is  set  up  with  three  sections,  the 
conditions,  the  rules  and  the  actions.  The  conditions  correspond 
to  the  contents  of  the  decision  diamond  of  the  flow  chart,  but 
providing  more  branches  or  alternatives  for  action.  The  actions 
represent  the  processing  blocks  of  the  flow  chart  presented  in  the 


sequence  of  execution  desired.  As  an  example,  the  sequence  of 
execution  for  a  transaction  record  for  which  there  is  a  master 
record  and  for  which  the  type  of  transaction  (purchase-Rule  five) 
would  bes 

1.  Match  transaction  record  number  with  master  record  number. 

2.  Match  transaction  type  with  rule  number. 

3.  Perform  actions  indicated  by  rule  number.  (In  this  case 
transaction  type  three  indicates  rule  number  five) 

4.  Perform  actions? 

a.  Add  purchase  order  to  balance  on  order. 

b.  Read  inventory  transaction  file  record. 

c.  Go  to  inventory  file  update  table,  (i.e.  -  Return 
to  beginning  of  this  table  and  read  next  transaction  record.) 

Two  advantages  of  the  decision  table  is  that  the  condition 
and  action  are  independent  and  all  conditions  are  tested  for  the 
applicable  rule  before  any  action  is  executed. 

These  methods  of  analysis  may  be  done  singularly  or  jointly  to 
perform  the  analyses  suitable  for  the  situation  or  problem  being 
studies. 

2.  Operational  Analysis 

This  phase  of  the  analysis  will  be  done  in  conjunction  with  the 
functional  analysis  phase  and  will  investigate  and  determine  the  best 
operational  procedures  to  be  used  in  developing  the  system.  It  may 
use  various  "operations  analysis"  techniques  such  as  Queuing  theory, 
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Linear  and  Dynamic  programming  methods  and  Monte  Carlo  methods. 
Caution  must  be  exercised  here  to  insure  that  the  solution  fits 
the  problem,,  Often  analysts  become  too  involved  in  an  extremely- 
sophisticated  solution  to  a  problem  that  does  not  require  this 
sophistication,,  If  the  solution  is  too  complex  to  understand  it 
will  not  be  used.  The  analyst  must  always  keep  in  mind  the  problem 
to  be  solved  and  solve  it  in  the  most  effective s  efficient  and 
least  complicated  method  possible,  "Don't  solve  the  wrong  problem." 

The  techniques  of  Operations  Analysis  are  widely  known  and 
used  within  the  data  processing  environment c  An  example  of  the 
use  of  Queuing  theory  and  Monte  Carlo  methods  in  automated  devel- 
opment could  be  the  simulation  of  data  elements  entering  the 
system  for  use  in  a  subroutine.  These  elements  may  have  an  arrival 
rate  that  may  approximate  a  certain  distribution  function.  The 
subroutine  may  process  these  elements  at  a  certain  service  rate 
which  would  approximate  an  exponential  distribution.  Using  various 
assumed  probabilities  and  Queuing  theory,  fairly  accurate  predictions 
can  be  made  for  processing  times  under  most  conditions.  This  is 
sufficient  to  indicate  that  competent  systems  analysts  must  be 
familiar  with  these  methods  and  able  to  make  sound  judgments  as  to 
when  and  how  to  employ  them  xn  obtaining  solutions  to  the  "problem.™ 

3,  Procedures  Development 

During  the  analysis  phase  the  procedures  development  plan  will 
be  made.  This  will  be  in  the  form  of  a  formal  functional  descript- 
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ion  of  the  system  in  a  prescribed  format.  This  may  be  described 
as  a  "documented  analysis  of  the  area  under  consideration  for 
automation"  including  all  conclusions  and  general  specifications 
for  the  proposed  system.   It  must  be  written  so  that  the  user 
(possibly  non  AUF  orientated)  will  have  a  clear  understanding  of 
the  impact  of  the  proposed  system  modification  and  encourage  user 
participation  in  the  project  development.  Below  is  a  summary  of 
the  contents  of  this  document.  Appendix  B  is  a  complete  outline 
of  the  format. 

In  providing  a  clear  statement  of  operational  capability  the 
functional  description  wills 

1.  Provide  a  basis  for  defining  the  work  to  be  accomplished 
and  the  program  to  be  developed e 

2.  Provide  in  writing  a  basis  for  mutual  understanding  of 
requirements  between  the  user  and  the  system  analyst. 

3.  Assist  in  obtaining  concurrence  between  the  user  and  the 
developer.  (System  Analyst) 

4.  Provide  the  user  with  information  requirements  necessary 
for  data  collection  and  preparation. 

To  accomplish  this,  the  functional  description  will  outline 
existing  procedures,  including  personnel  responsibilities,  present 
equipment,  files,  system  cycling  frequency,  time  delays  and  a 
block  diagram  description  of  information  transmitted  from  data 
receipt  through  processing  and  use.  Utilizing  the  techniques  of 

Naval  Command  Systems  Support  Activity  Instruction  5230. 1A 
17  July  1964. 
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information  flow  analysis  in  conjunction  with  the  methods  of 
simulation,  run  diagramming;,  flow  charting  and  decision  tables 
described  above,  the  documentation  will  outline  the  development  of 
the  proposed  system  and  present  a  comparison  of  the  two  systems. 
Alternate  recommendations  will  be  described  with  consideration 
given  to  the  costs  and  requirements  of  the  desired  system,,  Details 
will  be  provided  in  man-power  requirements,  machine  time,  equipment 
requirements  and  processing  times  for  development  and  operation  of 
the  system.  These  details  must  include  present  functions  or 
operations  that  are  being  deleted  and  functional  descriptions  of 
new  operating  procedures  including  a  capability  or  grade  level  of 
personnel  required. 

A  summary  of  the  impact  on  the  user  command  as  a  result  of 
the  installation  of  the  new  system  will  be  provided. 

A  detailed  description  of  the  following  elements  will  be 
provided? 

1.  Equipment  required. 

2.  System  programs  and  subprograms  to  be  used. 

3.  Data  requirements  including  files,  formats,  frequency 
and  sources. 

4.  Data  transformation  -  a  description  of  the  techniques 
and  processes  for  converting  input  data  into  required  formats. 

5.  Output  -  report  and  display  formats  will  be  described 
including  user,  content  of  report  or  display,  purpose  and  frequency, 

6.  Query  capability  -  a  description  of  the  query  procedure 
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including  types,  limitations  and  flexibility. 

7.  System  capacity  -  specifications  for  data  Volume,  accuracy 
and  response  time  available, 

8.  Manpower  requirements  -  A  summary  of  the  requirements  to: 

a,  Establish  the  data  base  for  the  system, 

b,  iMaintain  data  base, 

c,  Operate  and  maintain  the  program. 

The  completion  of  this  report,  its  review  and  acceptance  of 
the  concept  of  development  and  operation  by  the  user  completes  the 
analysis  phases  and  provides  a  firm  decision  on  the  concept  of  the 
system  development.  The  developer  now  has  a  solid  base  for  project 
completion  and  the  user  has  a  clear,  firm  description  of  what  will 
be  provided  as  an  automated  system.  Hereafter;  there  can  be  no 
change  in  concept  or  major  modification  of  method  of  development 
without  a  complete  reappraisal  of  the  entire  project. 

4.  Data  Collection 

Data  collection  will  be  the  main  responsibility  of  the  user. 
The  format  design  necessary  will  be  prepared  by  the  system  analysis 
group,  and  will  include  detailed  instructions  for  preparation.  The 
raw  data  to  be  received  will  be  outlined  and  data  card  columns, 
number  of  data  cards  required  and  frequency  of  preparation  will  be 
determined. 

Using  as  aids,  the  data  collection  format,  flow  charts  and 
decision  tables  prepared  in  the  design  and  analysis  phases,  the 
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various  standardized  inputs  formats  are  designed.  Here  the  ingenu- 
ity of  the  systems  analyst  is  taxed.  He  must  design  the  input 
formats  that  are  readily  understandable  by  the  user,  that  is, 
avoiding  the  requirement  for  complex  conversion  of  the  raw  data  into 
the  technical  computer  language  by  the  user.  Yet,  they  must 
contain  complete  information  properly  sequenced  so  as  to  permit 
relative  ease  of  conversion  to  the  computer  language  and  key 
punching  format  by  the  analyst.  There  must  also  be  the  attempt 
to  combine  logically  related  data  in  a  single  format,  but  avoid 
design  of  extremely  complex  or  unwieldy  documents.  The  effect- 
iveness of  the  program  will  be  no  better  than  the  validity  of 
the  data  entered,  therefore,  it  is  obvious  that  this  phase  is 
critical  to  the  successful  operation  of  the  system. 
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CHAPTER  IV 


DEVELOPMENT 


With  a  firm  concept  and  system  design  in  hand,  the  analysts, 
system  programmers,  and  programmers  may  commence  actual  program 
development.  This  will  consist  of  preparing  detail  program  flow 
charts,  program  coding  and  checkout.  This  development  is  accom- 
plished in  two  distinct  areas,  hardware  development  and  programming 
development, 

A.   HARDWARE  DEVELOPMENT 

Jf  required,  hardware  development  may  be  conducted  concurrently 
with  the  analysis.  Care  must  be  exercised  that  selection  of 
equipment  be  accomplished  without  preconceived  ideas  on  type  of 
equipment.  Equipment  must  fit  the  system.  The  system  should  not 
be  designed  around  equipment. 

In  certain  areas,  however,  such  as  command  and  control,  very 
large  capacity  equipments  are  in  use  and  development  of  subsystems 
within  the  command  and  control  area  must  have  the  equipment 
configuration  as  a  preset  parameter. 

Hardware  development  is  a  large  and  very  complex  study. 
Hardware  manufacturers  are  continuously  conducting  research  to 
design  and  produce  new  equipment  for  faster  more  accurate  process- 
ing method.  Apparently  the  main  problem  in  system  development  is 
being  able  to  define  the  requirements  well  enough  to  choose  the 
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proper  equipment. 

B.  PROGRAMMING  DEVELOPMENT 

The  term  programming  may  be  considered  in  two  wayss  that  of 
problem  analysis  and  that  of  writing  the  program  instructions.  In 
this  paper  it  refers  to  writing  the  program  instructions.  The 
functional  description  is  translated  into  detailed  flow  charts  and 
a  series  of  subprograms  and  subroutines.  Flow  charts  mentioned 
here  are  programming  flow  charts.  Programming  flow  charts  describe 
the  specific  operations  and  decisions  that  are  performed  in  a 
stored  memory  program. 

The  flow  chart  symbols  shown  in  Figure  1  are  used  for  the 
programming  flow  charts  as  well  as  the  structural  flow  charts. 
Various  decisions  must  be  made  prior  to  actual  coding  of  the 
system.  The  analyst  must  decide  on  the  language  in  which  the 
system  will  be  written.  Here,,  he  has  a  wide  variety  of  choices. 
Howevers  he  must  consider  several  parameters.  These  may  bes  the 
type  of  problem  -  scientific^  business  or  mathematical g  the 
frequency  with  which  the  problem  must  be  solved  ■=•  real  time  or 
delayed  processing  application  %   the  type  of  input  -  direct  from 
source  documents  or  via  some  intermediate  compiling  device.  If 
the  problem  is  scientific  a  programming  language  such  as  FORTRAN 
or  JOVIAL  may  be  required.  For  a  business  application  COBOL  may 
be  used.  These  are  only  a  few  of  the  criteria  that  may  be 
considered.  Many  more  could  be  necessary  depending  on  the  type 


and  complexity  of  the  problem.  Up  to  this  point  in  the  analysis 
no  mention  has  been  made  as  to  the  hardware  configuration.  It  was 
pointed  out  in  Chapter  IV,  Section  A, that  the  analysis  to  this 
point  need  not  consider  the  hardware  configuration.  The  analyst 
must  now  give  this  consideration.  Size  and  speed  of  the  computer 
may  be  a  limitation.  The  input  media  may  dictate  certain 
programming  methods.  An  example  would  be  the  methods  used  in 
programming  for  sequencial  processing  versus  those  used  for  random 
access  processing. 

Sequential  processing  uses  data  records  that  are  in  a  series 
storage  such  as  magnetic  tape  which  would  require  methods  of 
sorting  and  editing  that  scan  the  complete  file  in  order  to  extract 
or  correct  a  single  record.  Records  must  be  sequenced  in  the  most 
efficient  manner  so  that  information  required  most  often  is  near 
the  beginning  of  the  tape. 

Random  access  processing  will  not  have  this  limitation  in  that 
each  record  or  bit  of  information  can  be  obtained  independent  of 
other  information. 

Another  consideration  will  be  the  availability  of  compilers 
or  assemblers.  This  will  dictate  the  use  of  either  a  problem  - 
oriented  language  (machine  independent)  or  machine  -  oriented 
language  (machine  dependent).  The  use  of  a  machine  -  oriented 
language  requires  little  or  no  translation  into  computers  numeric 
ordi|r  code.  The  mnemonic  (alpha)  codes  would  require  translation 
on  a  one  for  one  basis.  The  use  of  a  problem  -  oriented  language, 
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such  as  Fortran,  Cobol,  Algol  or  Jovial,  however,  requires  the  use 
of  much  more  elaborate  translators  and  convert  each 

program  instruction  into  one  or  several  machine  instructions.  It 
is  obvious  that  if  these  translators  and  compilers  are  not  avail- 
able, then  these  also  must  be  developed.  This  will  add  to  the 
programming  complexity.  The  trade  offs  of  simplicity  and  efficiency 
of  the  machine  -  oriented  language  against  the  sophistication  and 
versatility  of  the  problem  -  oriented  language  must  be  considered 
in  the  light  of  the  problem  to  be  solved „ 

Generally  the  development  of  an  automated  system  to  perform 
some  set  of  objectives  will  not  stand  alone.  Automating  an 
inventory  control  function  will  usually  be  done  in  conjunction 
with  the  automation  of  the  procurement,  disposal s  accounting  and 
financial  control  functions  to  create  a  complete  system.  Also 
other  unrelated  functions  may  be  developed  for  the  same  organiza- 
tion or  activity.  In  order  to  design  and  develop  a  complete, 
integrated  system  it  is  necessary  to  create,  where  ever  possible, 
standardized  routines  and  procedures.  These  routines  usually 
perform  the  executive  function  of  an  integrated  system.  The  basic 
system  monitor  is  designed  to  perform  "housekeeping"  functions 
such  as i   execution  control  which  consists  of  standardized  routines 
for  loading  and  sequencing  programs,  input-output  control,  inter- 
computer communications  control  and  time  sharing  program  control. 
The  availability  of  these  routines  in  an  integrated  system 
eliminates  the  necessity  for  detail  programming  to  control  these 
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operations.  It  does,  however,  demand  the  adherence  to  standardized 
programming  rules.  This  standardization  generally  simplifies  the 
programmers  task  but  may  have  the  disadvantage  of  less  efficient 
operation  of  the  individual  program.  This  decrease  in  efficiency 
is  usually  acceptable  since  the  use  of  standard  routines  will 
increase  the  overall  efficiency  of  the  integrated  system.  With  the 
various  "tools"  mentioned  above,  the  programmer  is  able  to  translate 
from  the  detailed  program  flow  charts  and  decision  tables  to  the 
programming  code.  When  writing  the  source  program,  the  programmer 
must  define  each  data  file  and  table  to  be  used  by  the  type  of 
file-card,  tape  or  disk;  type  of  processing  -  random  or  sequential 
and  the  method  used  for  spacing  and  over  flow. 

He  must  specify  the  input  -  output  requirements  including 
the  Macro-Instruction  controls  for  insertion  and  retrieval  at  the 
proper  point  in  the  program.  Utility  routines,  such  as  card  to 
tape,  tape  to  print,  disk  to  tape,  etc;  must  be  properly  called 
and  sequenced  to  provide  a  smooth  integration  of  the  computational 
and  input-output  operation  of  the  program. 

Consideration  must  be  given  to  querying  methodology  including 
types,  limitations,  flexibility,  report  formats  and  output  displays* 

The  programming  development  will  provide  extensive  document- 
ation on  all  programs.  This  documentation  is  the  heart  of  the 
operational  process  of  the  system.  It  will  contain  a  user  or  staff 
(nonADP)  section  which  will  provide  a  system  description  giving 
the  capabilities  and  limitations  oriented  toward  users  having  no 
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technical  background  in  ADP.  It  will  contain  the  description  of 
system  inputs  including  the  source  ,  the  type  ( forms  ,  data  cards, 
punched  tape,  etc.)  the  volume  «&nd  frequency,,  It  will  also 
contain  the  system  output*  describing  in  detail  the  type,  (report 
forms,  data  card,  magnetic  tape,  visual  displays,  etc.)  format 
and  frequency. 

The  "technical  operations'*  section  will  be  written  in  more 
technical  language  for  use  by  the  maintenance  programmer  and  ADP 
operations  personnel.  It  will  contain  detailed  flow  charts,  the 
symbolic  and  machine  listings  of  each  program  or  subprogram. 

Detailed  methods  of  query  preparation  for  gaining  access  to 
information  other  than  from  scheduled  reports  procedures  will  be 
provided. 

The  "system  operation"  section  will  describe  the  computer  set 
up  and  operation  providing  detailed  online  input/output  processes 
such  ass  printer,  card-reader,  type  units^,  display  equipment,  etc.. 
It  will  also  provide  details  on  data  arrangement 5  tape  mounting, 
sense  switch  setting,  running  time,  output  disposition,  error 
check,  EAM  procedures,  control  procedures,  etc..  Appendix  C  gives 
a  complete  outline  of  the  final  dlocumentation. 

C.  TESTING  AND  CHECKOUT 

During  programming  development  the  various  subprograms, 
utility  programs  and  subroutines  must  be  tested  to  insure  accurate, 
properly  operating  systems.  This  is  usually  referred  to  as 

49 


"debugging."  It  will  involve  checkout  on  the  computer  for  which 
the  system  is  designed ,  All  subroutines  must  be  tested  separately 
and  in  conjunction  with  others  to  insure  compatability  of  the 
system.  During  this  period  corrections  and  modifications  continue 
in  order  to  develop  the  most  efficient  and  dynamic  system  possible. 
Here  it  is  necessary  to  stress  the  accuracy  and  completeness  of 
the  changes  to  the  program  documentation.  This  is  vital  for  future 
maintenance  and  modification  to  the  system. 

D.  MODIFICATION 

Unless  an  automated  system  is  extremely  limited  in  scope,  it 
must  be  dynamic  and  contain  the  capability  to  be  modified  and 
changed.  In  order  to  perform  these  changes  and  modifications,  at 
some  future  time  when  those  originating  may  not  be  available,  the 
original  program  documentation  must  be  complete  and  clear.  Proce- 
dures must  be  instituted  that  will  insure  that  programming  instruc- 
tions (additions  and  deletions)  are  fully  documented  when  they  are 
accomplished c  A  complete  history  of  program  development  and  modifi- 
cation  should  be  available „     This  can  only  be  accomplished  by 
management  establishing  and  enforcing  rigid  policies  concerning 
documentation  standards  and  procedures.  This  is  not  to  be  done 
to  preclude  making  changes  but  to  insure  a  complete  record  of 
those  made. 

There  have  been  several  methods  developed  that  will  automat- 
ically prepare  a  record  of  any  modification  made  to  the  program. 
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Section  III-B  mentions  two  ©f  these ,  Auto sate  and  Documentations 
Aids  System.  As  mentioned  previously  the  D.A.  System  is  very 
useful  as  a  maintenance  tool  for  automated  systems.  Here  it  would 
be  ideal  for  modification. 

This  system  consists  of  four  programs  and  processes  source 
programs  written  in  Symbolic  Programming  System  (SPS),  Autocoder, 

Macro  Assembly  Program  (MAP),  Fortran  Assembly  Program  (FAP)  or 

7 
Symbolic  Flowchart  Language  (SFL)  for  various  IBM  machine  systems. 

It  produces  the  following  program  documentations 

1.  A  storage  map  of  object  decks. 

2.  An  analysis  listing  of  source  decks. 

3.  A  flowchart  of  source  decks. 

These  programs  are  the  update  program,  the  analysis  program,  the 
flow  chart  program,  and  the  verification  program. 

The  update  program  is  used  to  insert,  delete  or  replace 
programming  instructions  in  the  source  program.  It  performs  these 
functions  by  a  file  maintenance  routine.  It  is  also  used  to  update 
the  symbolic  flow  chart  language ,  conduct  sequence  checking  and 
prepare  an  input  tape  for  the  analysis  and  flow  charting  programs « 

As  it  implies,  the  analysis  program  provides  a  detailed 
analysis  of  each  program  instruction  giving  a  listing  denoting 
the  type  of  instruction  (relative  addressing,  indexing,  indirect 
addressing  or  data  defining),  a  cross  reference  dictionary  of 
symbols  used  and  a  statistical  analysis  of  the  operations  codes, 

IBM  Document  no.  H20-0133-0  (1964)  p.  1. 
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i.e.  -  the  frequency  of  occurrence  of  each  code. 

The  flow  charting  program  generates  an  updated  flow  chart 
presenting  the  logic  of  the  source  program  and  uses  the  output  of 
the  analysis  program  to  produce  the  "symbolic  flow  chart  language. n 

The  verification  program  is  designed  to  assist  the  programmer 
in  comparing  the  source  program  with  the  current  object  program  by 
producing  a  storage  map  which  presents  the  contents  of  core  storage 
after  the  object  program  is  loaded.  It  provides  location  sequences 
and  identifies  all  program  patches  made  to  the  object  program. 

The  use  of  these  four  programs  should  substantially  ease  the 
workload  of  the  maintenance  programmer.  It  is  again  pointed  out 
that  this  simplification  can  only  be  accomplished  if  the  original 
documentation  is  reliable. 

With  the  completion  of  the  development  phase  the  automated 
system  is  available  for  evaluation  and  use  by  the  user  activity. 
In  order  to  consolidate  the  documentation  described  in  this  paper 
Appendix  D  is  provided  as  a  summary  of  all  documentation  needed  to 
maintain  and  modify  the  system  when  required. 
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CHAPTER  V 


EVALUATION  AND  OPERATION 


With  the  completion  ©f  the  testing  and  checkout  phase,  the 
system  is  theoretically  ready  for  operational  evaluation.  This 
should  be  done  under  actual  operating  or  simulated  operating 
conditions  for  a  specified  period  of  time,,  These  evaluations 
tests  must  be  conducted  by  operations  personnel  under  the  super- 
vision of  the  systems  analysis  group  and  observed  by  the  users. 
This  will  give  all  concerned  the  opportunity  to  evaluate  and 
become  familiar  with  the  system.  It  will  also  provide  a  vehicle 
for  communication  of  criticism  or  suggestion  for  more  efficient 
operation.  Cost  of  effectiveness  studies  may  now  be  conducted  to 
determine  the  increase  of  functional  efficiency  gained  by  the 
installation  of  the  automated  system.  The  final  acceptance  of 
the  complete  system  is  formally  prepared  releasing  the  developer 
from  further  responsibility.  The  continued  maintenance  and 
modification  of  the  system  will  now  be  the  responsibility  of  the 
user  activity. 
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CHAPTER  VI 
CONCLUSIONS  AND  ACKNOWLEDGEMENTS 

While  the  technological  developments  in  the  field  of  auto- 
mation have  advanced  by  great  strides  in  the  past  twenty  years, 
the  administrative  progress  has  moved  very  slowly.  The  great 
speed  and  versatility  of  present  day  computers  are  being  hindered 
by  the  lack  of  proper  administrative  control. 

The  day  of  program  development  by  the  "seat  of  the  pants" 
programmer  has  past.  Automated  systems  have  become  so  complex 
and  the  problems  that  are  being  solved  are  so  complicated  that 
systems  development  requires  sophisticated  procedures  that  can 
only  be  followed  by  proper  and  adequate  recording  as  development 
progresses. 

An  automated  system  without  complete  documentation  will  fall 
into  disuse  because  the  reprogramming  effort  required  may  be  as 
great  as  for  the  original  development. 

If  adequate  documentation  is  provided,  including  a  complete 
system  description,  flow  charts,  block  diagrams  and  anotated 
listings  of  all  systems  and  subroutines  as  is  contained  in  section 
VII,  the  modifications  and/or  changes  may  only  require  the  efforts 
of  relatively  few  experienced  analysts  and  programmers. 

The  key  to  successful  cost  effective  automated  systems  is, 
therefore,  complete,  clear  and  timely  documents  produced  during 
the  development. 
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This  paper  outlines  an  approach  to  the  solution  to  the 
problem  of  inadequate  or  improper  documentation  in  the  development 
of  an  automated  systenu  It  is  written  in  an  effort  to  promote  an 
interest  in  this  problem.  There  may  be  other  approaches  that  are 
being  used  in  the  field  of  automation.  There  have  been  many 
articles  written  on  document  and  data  element  standards  as  evidenced 

by  scanning  the  recent  American  Computing  Machinery  index  to  the 

8 
computing  reviews.   However ,  the  author  has  been  unable  to  find 

any  specific  references  to  the  standardization  of  analysis  and 

programming  procedures  and  documentation  other  than  those  mentioned 

in  this  paper. 

As  it  was  pointed  outs  the  government  has  taken  an  interest 
by  advocating  more  stress  be  placed  on  standardization  of  computer 
and  system  development  techniques.  There  is  a  great  deal  yet  to  be 
accomplished.  The  Data  Processing  System  Manager  has  the  responsi- 
bility to  produce  an  efficient  operating  system.  In  order  to  do 
this  he  must  have  all  the  tools  to  perform  the  task.  With  a  system 
properly  analyzed,  developed  and  documented  he  will  be  able  to 
maintain  efficient  operation  procedures. 

In  conclusion  I  would  like  to  acknowledge  the  advice  and 

constructive  criticism  provided  in  writing  this  paper  by  Professor 

James  B.  Cowie.  It  has  helped  develop  the  area  of  interest  and 

concern  to  me» 

g 
Association  for  Computing  Machinery,  Computing  Reviews  1960- 
1963. 
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APPENDIX  A 
REPORT  OF  DESIGN  STUDY 

I.  Title  Page 

II.  Abstract 

A  clear  and  concise  statement  of  the  content  of  the  document, 

III.  Table  of  Contents 

IV.  Introduction 

A.   Background 

1.  Requirement  -  An  analysis  of  the  requirement  contained 
in  the  project  request  presenting  clear  definitions 

as  to  statements  contained  therein. 

2.  Staff  Responsibilities  -  A  definition  and  explanation 
of  the  present  staff  responsibilities  and  the  desired 
capabilities  to  be  provided  by  the  completion  of  the 
subject  project. 

V.  Analysis 

A.  Environment 

1.  Organizational  Relationships  -  A  reference  may  be 
made  here  to  information  flow  and  the  various  inter- 
actions of  the  staff  with  other  users. 

2.  Problem  Areas  -  A  definition  of  problem  areas  encountered. 

B.  Present  Methods  and  Procedures  -  A  discusion  of  the 
present  staff  methods  and  procedures  in  performing  the 
functions  outlined  in  the  subject  project  request. 
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C.   System  Analysis  -  an  analysis  of  the  present  system  and 
proposed  system  development, 

VI.  Comments  and  Recommendations 

Ac   Present  Capabilities  -  A  statement  and  analysis  of  the 

adequacy  of  the  present  capabilities. 
B.   Proposed  System  Requirements 

1.  Non-ADP  -  Recommendations  as  to  improvements  of  present 

capabilities  which  would  not  require  the  use  of  ADP 
systems . 

2.  ADP  -  Recommendations  as  to  proposed  improvements  of 
present  capabilities  which  would  require  the  use  of 
ADP  systems, 

APPENDIX  1 

Flow  charts  of  the  present  system. 
APPENDIX  2 

Flow  charts  of  the  proposed  system. 
APPENDIX  3 

Reports  on  location  characteristics  and  relationships. 

Reports  on  Network  load  analysis. 

Reports  on  Documentation  Activity  Analysis. 

Reports  on  File  Analysis. 

VII.  Glossary 
VII I. Bibliography 
IX.  Distribution. 
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APPENDIX  B 
PRELBtiNARY  FUNCTIONAL  DESCRIPTION  FORMAT 

A.  Introduction 

The  requirement.  A  statement  of  the  established  requirement 
with  appropriate  references, 

B.  Existing  Methods  and  Procedures 

1.  A  description  of  existing  methods  and  procedures,  including 
personnel  responsibilities,  equipments,  volumes,  frequencies,  time 
delays  and  a  block  diagram  description  of  information  transmitted 
from  the  beginning  of  data  acquisition  through  its  processing  and 
eventual  use. 

2.  Throughout  this  over-all  analysis  of  the  user*s  present 
system,  quantitative  as  well  as  qualitative  values  which  support 
justification  for  the  need  of  improvement  must  be  developed. 

C.  Proposed  Methods  and  Procedures 

1.  A  definitive  description  of  the  capability  upon  which 
project  design  will  be  based.  Emphasis  should  be  placed  on 
differences  from  the  existing  system.  A  block  diagram  of  the 
proposed  system  will  present  an  over-all  view  of  the  planned 
capability. 

2.  The  description  of  the  proposed  methods  and  procedures 
must  be  developed  in  sufficient  depth  to  demonstrate  the  impact 
on  man-power,  machine  time,  equipment  requirements,  processing 
times  and  throughput.  Where  appropriate,  alternative  methods  and 
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procedures  will  be  described  with  subsequent  discussion  of  the 
rationale  for  the  final  selection. 
D.   Environment  and  Impact 

1.  A  summary  of  the  impact  on  the  user  command  by  the 
installation  of  the  proposed  system.  This  discussion  should  include 
those  elements  noted  in  paragraph  C  as  well  as  the  modifications  to 
responsibilities  which  may  result. 

2.  A  detailed  description  of  the  following  elements  is 
required. 

a.  Equipment  needed  to  support  the  proposed  system 

b.  System  programs  to  be  employed 

c.  Data  t©  support  the  system  =■  volumes ,  formats,  adequacy, 
frequency,  sources. 

d.  Data  transformation.  A  description  of  the  techniques 
and  processes  involved  in  converting  the  input  data  into  the  form 
required  for  files  or  for  outputs.  This  may  include  a  brief 
description  of  the  mathematical  models  used. 

e.  Reports  and  Displays.  A  description  of  each  report 
and  display,  the  frequency  and  timeliness  with  which  it  is  required, 
and  the  events  which  initiate  its  preparation.  The  description  will 
list  the  user,  content  and  purpose  of  the  report  or  display. 

f.  Queries.  A  description  of  query  methodology  including 
types  of  queries,  limitations,,  query  flexibility  and  throughput 
time. 

g.  System  Capacity  Requirements  and  Cons trains t.  A 
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quantitative  specification  of  data  volume,  the  accuracy  required, 
the  response  time  for  routine  and  emergency  situations  and  any 
limitations  which  affect  the  desired  capability. 
3.  Manpower  Requirements 

a.  To  establish  the  data  base  required  to  initiate  the 
subsystem. 

b.  To  maintain  the  data  base 

c.  To  operate  and  maintain  the  programs 

d.  To  effectively  use  the  capability 
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APPENDIX.  C 

FINAL  DOCUMENTATION  OUTLINE 

Cover 

Title  Page 

Detailed  Table  of  Contents 

I.   STAFF  MANUAL  SECTION 

A.  SYSTEM  DESCRIPTION 

A  general  description  of  the  capability  will  be  provided. 
It  will  be  oriented  towards  an  audience  of  users  who  have 
no  technical  background  in  ADP.  This  description  will 
specify  in  layman  terms,  the  usefulness  of  the  capability 
to  the  user. 

B.  SYSTEM  INPUTS 

1.   Staff  sources,  for  data  base  preparation 
a.   Identity  of  source 

(1)  type 

(2)  expected  volume  per  unit  of  time 

C.  SYSTEM  OUTPUTS 

1.   General  description 

a.   Identity  and  description  of  output 

(1)  type 

(2)  expected  frequency  and  volume 
disposition  of  output 
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2.   Detailed  description 

a.   Identity  of  output 

(1)  Format 

(2)  Explanation  of  symbols 

(3)  Intended  use 
II.  TECHNICAL  OPERATIONS  SECTION 

A.  QUERY  PREPARATION 

1.   Method  of  retrieving  information  and  report  generation 
if  a  standard  retrieval  method  is  not  used.  Otherwise, 
a  reference  to  standard  methods  of  retrieval  already 
in  use  should  be  given. 

a.  Query  forms  (Including  formatted  creation  sheets) 

b.  Format  table 

B.  SYSTEM  OPERATION 

1.   Console  setup  and  operation 
a.   General 

(1)  Computers  used 

(2)  On-line  in put /output  components  used  such 


as: 

(a 

(b 

(c 

(d 

(e 

(f 


Printer 

Card  reader 

Number  and  type  of  tape  units 

System  tapes  utilized 

Disc 

Digital  plotter 
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(g)  Display  equipment 
b.   Specific 

(1)  Details  related  to  above  input/output 
components  such  ass 

(a)  Use  of  on-line  printer 

(b)  Proper  arrangements  of  card  decks 
(deck  structure) 

(c)  Disposition  of  all  output 

(d)  Instructions  for  mounting  tape,  and 
tape  densities  (if  applicable) 

(2)  Sense  switch  settings 

(3)  Approximate  running  time 

(4)  Each  separate  operations  performed  should 
be  clearly  outlined 

2.  Description  of  halts 

a.  Condition  (which  caused  the  halt)  NORMAL  or 
ABNORMAL  indicates  to  operator  type  of  error 

b.  Printout  (which  will  appear  with  a  particular 
halt) 

c.  Response  (action  operator  should  execute) 

3.  EAM  Procedures 

a.  Key  punch  instructions 

b.  Data  sorting  and  collating  instructions 

4.  Control  procedures 

a.  In-out  origin 

b.  Routing  procedures  for  machine  input 
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c.   Responsibilities  for  control  and  disposition 

(cards,  listings,  etc.) 
5.   Recommended  operators  run  sheet  (an  annotated 

equipment  setup  summary  for  operator  ready  reference) 
III.  PROGRAM  SYSTEM  MAINTENANCE  SECTION 

A.  SYSTEM  DESCRIPTION 

A  description  of  the  logical  development  of  the  solution 
by  the  program  and  the  relationship  between  routines. 
The  interrelation  with  other  programs  is  defined. 
Operating  system  capacities  and  restrictions  will  be 
defined  or  referenced. 

B.  DATA  BASE  DESCRIPTION 

A  description  of  the  basic  files  maintained  by  and/or 
for  the  system. 

1.  Physical  characteristics 

size,  storage 

2.  Format  characteristics 

Item  definitions  and  descriptions,  format  type 

3 .  Updating 

4.  Classification 

C.  DETAILED  PROGRAM  DESCRIPTIONS 
1.   Program  Title 

a.  Synopsis 

b.  Functional  description 

c.  Flow  charts 
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d.  Annotated  listing 

e.  Capacities  and  restrictions 

f .  Halt  and  error  conditioning 

2.  Inputs 

3.  Outputs 

4.  Internal  tables,  formats,  and  techniques 

Description  of  internal  tables  Modification 

and  updating 

COMPOOL 

5.  Programmer  log 
IV.  APPENDICES 

Glossary- 
Bibliography 

Special  Additional  Information  as  Needed 
Examples  Mathematical  Proofs 
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APPENDIX  D 

DOCUMENTATION  SUMMARY 

The  following  is  a  summary  of  the  documentation  to  be  prepared 
during  the  development  of  an  automated  system. 

A.  The  Planning  Phase 

1.  System  Requirement  Documentation  prepared  by  the 
user, 

2.  Report  of  Design  Study 
Prepared  by  the  Systems  Analysts 

B.  Analysis  Phase 

1.  Development  Plan 

Prepared  by  the  Systems  Analysts  and  Programmers 
giving  manpower,  cost  and  time  phasing  estimates 
for  system  development,, 

2.  Functional  Description 

Prepared  by  the  Systems  Analysts  giving  a  detailed 
description  of  method  for  automating  the  system. 

C.  Development  Phase 

1.   Technical  Documentation  Manual 

Developed  in  three  sections  -  User  Section, 
Technical  Operations  (lection,  System  Operation 
Section  and  is  the  basic  documentation  for 
operations,  maintenance  and  modification  of  the 
sys  tern . 
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